系列：從現場踩坑到 AI 工具 — IT Diagnostic Agent 開發實錄
本篇為系列核心篇之一

一個 Prompt 工程永遠無法解決的問題

前兩天定下了五條規則和決策相關性測試。

看起來事情做完了：把規則寫進 systemPrompt，LLM 照著做，完美。

但這裡有一個所有做過 Prompt 工程的人都知道的問題：

你寫進 Prompt 的規則，LLM 不保證會遵守。

它大部分時候會遵守。但「大部分時候」在故障排查的情境下不夠好——因為當它不遵守的那次，使用者正在停線。

規則寫得再好，只要執行依賴模型自律，可靠性就有上限。

兩種讓 AI 遵守規則的方式

這件事其實有兩條路：

路徑 A：告訴它（Prompt）
把規則寫成文字，放進 systemPrompt，期待它遵守。

• 優點：彈性極高，任何情境都能處理
• 缺點：機率性的。可能不遵守，而且你不知道哪次會不遵守

路徑 B：讓它不可能違反（架構）
把規則做進系統結構，讓違反規則在技術上不可能發生。

• 優點：確定性的。100% 遵守，因為沒有別的路可走
• 缺點：彈性極低。結構沒涵蓋的情況，完全沒有路

大部分 AI 應用選 A，因為 A 好做。

IT Diagnostic Agent 的主要路徑選了 B。而且說實話，我一開始不是有意識地選的。

我的決策樹早就在做這件事，只是我沒意識到

這是這整個系列裡最讓我意外的發現。

在跟 Claude 討論完 Evidence-driven Dialogue 之後，我請它幫我 clone GitHub repo，實際檢查我的程式碼有沒有符合這五條規則。

稽核結果是：Decision Tree、Runbook、Deep Diagnosis 這三種樹狀走訪模式，全部滿足五條規則。

而且不是因為我在 Prompt 裡寫了什麼——是因為靜態樹的結構本身就強制了這些規則。

逐條對照：結構如何強制紀律

規則 1 — 不要跳到結論

Prompt 做法： 「請不要在證據不足時給出結論。」（期待模型自律）

結構做法： 節點之間只有一種前進方式——使用者點選一個已定義的分支。

程式碼不允許從節點 A 直接跳到結論節點 Z，因為兩者之間沒有邊。

「跳到結論」在這個架構裡不是被禁止的行為，是不存在的操作。

規則 2 — 先問資訊增益最高的問題

Prompt 做法： 「請先問資訊增益最高的問題。」（期待模型正確判斷）

結構做法： 問題順序是我在寫節點時決定的。

這是一個**設計時（design-time）的決策，而不是執行時（runtime）**的判斷。

我在寫「換一條線試試」這個第一節點的時候，就已經替所有使用者做完了那個判斷。LLM 沒有機會判斷錯，因為它沒有機會判斷。

這條是我認為結構做法最強的地方：它把一個需要專業判斷的動態決策，變成了一個由專家事先固化的靜態結構。

規則 3 — 問完之後等使用者回答

Prompt 做法： 「WAIT USER REPLY. Do not self-answer.」

結構做法： UI 停在那個節點，直到使用者點下按鈕才會前進。

沒有點按鈕，狀態就不會變。自問自答在這個架構裡是物理上不可能的。

這條對照最能說明兩種路徑的差距。Prompt 只能請求，結構直接讓它做不到。

規則 4 — 只在收到新證據後更新診斷

Prompt 做法： 「只在收到新證據後更新診斷。」

結構做法： 狀態變更的唯一觸發來源是使用者的選擇事件。

沒有事件，沒有狀態轉移。這條在程式碼裡就是這樣寫的，不需要額外強制。

規則 5 — 不要列舉所有可能性

Prompt 做法： 「不要列舉所有可能性，除非使用者要求。」

結構做法： 每個節點只呈現 2 到 4 個選項。

十五條清單放不進一個節點卡片，因為卡片就不是那樣設計的。版面限制成了紀律的執行機制。

這個機制的正式名稱：人工撰寫的節點閘門

Claude 在稽核報告裡用的說法是 static gating enforced by code, not LLM self-restraint——由程式碼強制的靜態閘門，而非 LLM 自我約束。

我覺得這個描述很準確。每一個節點都是一道閘門，而閘門是人（我）寫的，不是模型即時生成的。

整個工具的紀律，來自於它的節點是人類專家寫的，而不是來自模型有多聽話。

誠實面對這個做法的代價

我花了三天在講結構的好處，但它的代價是真實的，而且很痛。

代價 1：樹外無路

如果一個故障不在樹上，使用者就走不到任何地方。

我寫了網路、硬體、帳號、印表機、軟體幾大類，涵蓋了我認為最常見的情況。但現場的故障組合是無限的。

第 81 個百分位的怪問題，這棵樹完全幫不上忙。

代價 2：維護成本轉移給人

決策樹的品質完全等於寫它的人的品質。

如果我對某個領域判斷錯了，那個錯誤會被固化進結構裡，而且不會像 LLM 那樣有機會「這次剛好答對」。錯的節點永遠是錯的，直到有人去改。

代價 3：擴充需要專業，不能靠生成

我不能叫 AI 幫我生一百個節點就收工。因為節點的價值來自判斷，而判斷需要有人負責。

這也是為什麼我把「從零動態生成節點卡片」列為刻意不做的功能。不是做不到，是那會摧毀這個架構唯一的優勢。

所以 AI 在這個架構裡的位置

那 AI 呢？完全沒用嗎？

不是。它負責的正是結構涵蓋不到的那 20%：

使用者進入 → 決策樹引導（結構強制紀律，覆蓋 80%）
                ↓
          走到底了但沒解決 / 情況不在樹上
                ↓
          切換 AI 對話模式（彈性，處理剩下 20%）

結構負責可靠性，AI 負責覆蓋率。

這是一個刻意的分工，而不是「AI 是主角，決策樹是備案」。順序反過來的產品，我在 Day 02 已經批評過了。

結構化地看這個選擇

核心 vs 外部
核心是「診斷紀律要可靠」。Prompt 是外部手段，結構是核心手段。當兩者衝突時，選結構。

可控 vs 不可控
LLM 的即時判斷是不可控的。我事先寫好的節點是可控的。把關鍵路徑放在可控的部分。

確定 vs 機率
Prompt 給你機率性的遵守，結構給你確定性的遵守。在故障排查這個領域，我願意用彈性換確定性。

今天的反思

紀律不該依賴自律，該依賴結構。

這句話在管理上是老話，在 AI 應用上我覺得還沒被講夠。

太多產品把「怎麼寫出更好的 Prompt」當成核心挑戰，卻沒問一個更前面的問題：這條規則有沒有可能不靠 Prompt，直接做進架構裡？

如果可以，那就不要靠 Prompt。

明天預告： 稽核結果不是全部通過。我的樹狀模式全過了，但有一個路徑一條規則都沒守——而那正是最需要它們的地方。

作者：Rich Chang | IT 基礎建設工程師 | 越南・柬埔寨・台灣